Video conferencing among two or more computers has been performed in the past by connecting separate web browsers running on separate computers to a remote server. Web browsers may be referred to herein as “web applications” or “browsers.” Examples of common web browsers include Google® Chrome™, Microsoft® Internet Explorer®, Mozilla® Firefox®, Apple® Safari®, among others. Once connections are established between the various web browsers and the remote server, content and control information may be provided from the server to the various browsers running on the various computers. For example, the server may receive streaming content from each browser, processes the streaming content, and make the content available back to the browsers in a formatted manner. The remote server controls the information that is received and made available to the browsers on an individual basis. If a browser seeks to change a format or otherwise provide modified control information, such control information is transmitted to and processed by the remote server. Depending on the processing, the remote server might modify content, format or control information made available to all or some of the browsers. In this manner, functionality of the browsers supporting the videoconference requires communication and processing by the remote server.
In instances where the server operates to provide control and content information to the browsers, latency is incurred as information is processed from one browser and made available to the others. For example, such information might move through several stages of processing and transmission: the information may be initially processed by a browser for transmission to the server, the information may be transmitted through the web, the information may be received and processed by the server, action may be taken and the result may be made available to any other appropriate browsers connected to the server. The server in such instance carries a substantial portion of the processing load.
Such deficiencies discourage the use of multiple browsers at a single location. If it were attempted, latency would be expected and additional loads would be placed on the server among other things. Even if two browsers were open in a single browser application loaded on a single machine, they would still be expected to coordinate through the server thereby incurring the undesirable latency, server burden and other problems.
When two separate browser instances wish to communicate information (i.e., two separate browser windows open on the same machine), a conventional technique involves use of a “hanging get” or the like to facilitate communications. When a first browser communicates a message to a second browser, the local machine on which the two browsers are running makes a request over the Internet to a remote server to open a communication channel between the local machine and the remote server. When the remote server receives the request, the remote server leaves a communication link between the remote server and the local machine that is executing the two browsers. The local machine is able to send information to the remote server when needed. After processing, the server can then make the information available to the second browser. In this manner, hanging gets allow the remote server to push notifications to the local machine without the local machine having to poll for updates. Also, when a first browser wants to send a message to another browser, the first browser may post a message to the remote server over HTTP via the communication channel. In response, the remote server may write the message back to the other connected browser(s) over the established “hanging get” communication channel to complete the notification from the first browser to the second browser.
Hanging gets provide an expensive implementation, from the server's standpoint, because the server has to keep this a hanging get communication channel open until the local machine is disconnected. This limits the number of simultaneous connections the server can handle, which means the service being provided does not scale well. There is also a latency problem with hanging gets because messages are transmitted from the client to the remote server and then back. In addition, a discovery problem exists since the server needs to know which browser should receive the message when the server sends the message back to the client via the communication channel.
Accordingly, there remains a need for a method and apparatus providing synchronization and control for server-based multi-screen videoconferencing. There further remains a need for a method and apparatus allowing two browsers to communicate while addressing the drawbacks and limitations discussed above.